home *** CD-ROM | disk | FTP | other *** search
/ Atari Mega Archive 1 / Atari Mega Archive - Volume 1.iso / lists / gem / l_0399 / 340 < prev    next >
Encoding:
Internet Message Format  |  1994-08-27  |  3.8 KB
  1. Subject: Digested
  2. Date: Tue, 07 Jun 1994 13:24:24 +1000
  3. From: Warwick Allison <warwick@cs.uq.oz.au>
  4. Precedence: bulk
  5.  
  6.  
  7.  
  8. There appears to be a growing agreement that KEYBOARD.SYS become ????.SYS,
  9. an application defaults file.  I agree.  I suggest we simply use something
  10. like the Xdefaults file format.  That is, basically a file of:
  11.  
  12.     ATTRIBUTE_PATTERN: VALUE
  13.  
  14. lines.  ATTRIBUTE_PATTERN is a wildcard match of attributes, such as:
  15.  
  16.     *SaveAs*
  17.  
  18. VALUE is an ASCII string.  It is converted to whatever internal value is
  19. required by std routines (eg. std way to convert ASCII to an integer,
  20. std way to convert ASCII to a keycode, etc.)
  21.  
  22. Example conversions:
  23.  
  24. integers:
  25.     103854  // decimal
  26.     01774   // octal
  27.     0x774   // hex
  28.     five    // :)
  29.  
  30. keys:
  31.     0x8831 // scancode
  32.     Ctrl-C // human
  33.  
  34.  
  35. Re CODES
  36.  
  37. Is this for humans or machines?  You don't have a hope in hell of making
  38. codes unique in a key bindings file!  Parsing strings is no more difficult
  39. than parsing numbers!  This talk of `put such-and-such in the 1000+ range'
  40. scares the euphemisms out of me.
  41.  
  42. Co-ordinating the distribution of numbers to application-operations
  43. would be impossible.  How do we make sure every `Save' is #1754?  Every
  44. `Resize' is #765?  Every `Insert Date' is #288? 
  45.  
  46. The mistake has been made once for ASSIGN.SYS (no-one knows how to use it).
  47. Don't repeat that mistake.
  48.  
  49.  
  50.  
  51.  
  52. Annius:
  53. > In a very simple formalism.  I'm convinced that we need to separate
  54. > codes into default sections,  class dedicated sections and
  55. > application-specific codes.
  56.  
  57. Dedicated sections can be achieved by following the
  58. Xdefaults method, where `sections' are just prefixes to the attribute,
  59. ie.
  60.  
  61.      *Edith.*SaveAs: Ctrl-A
  62.  
  63. Which matches:
  64.     Editor.Edith.SaveAs
  65.     Editor.Edith.Binary.SaveAs
  66.  
  67. but not:
  68.     Editor.Everest.SaveAs
  69.  
  70. Whereas:
  71.      Editor.*SaveAs: Ctrl-A
  72.  
  73. matches:
  74.     Editor.Everest.SaveAs
  75.     Editor.Edith.SaveAs
  76.     Editor.Edith.Binary.SaveAs
  77.  
  78. but not:
  79.     Painter.TruePaint.SaveAs
  80.  
  81.  
  82. Annius:
  83. > I think all applications should protect
  84. > their resources by including them into the binary.
  85.  
  86. That depends.  Freeware should certainly never be done this way.  Separate
  87. files allows native-language-speakers to create local versions.  Shareware
  88. too.  Commercial products... well, they should work in all languages the
  89. product is sold to, so editing should not be needed.
  90.  
  91. Then again... I wish I could 3D-ize all my applications by modifying their
  92. RSC files.
  93.  
  94. A scummy hacker will have a program to change `Annius Groenink' into
  95. `CRACKING ROOLZZ' whether in RSC file or binary.
  96.  
  97.  
  98. Timothy Miller:
  99. > If the shortcuts are configurable, then there's no point in having a 
  100. > standard because people can set it to however they want.
  101.  
  102. Unfortunately, not all humans are clones of me, so they all have
  103. different preferences.  Also, they unfortunately don't all speak the
  104. same language as me.  The fools even insist on having different keyboards
  105. which make certain keys (eg. [ and ]) less accessible than they are on
  106. my keyboard.  Or the non-clones buy non-atari keyboards.
  107.  
  108. All this Free Choice really gets on my nerves (why can't we all be like me?),
  109. but it is unfortunately the case, to configurability is necessary.
  110.  
  111. [now... back to Normandy]
  112.  
  113.  
  114. Timothy Miller:
  115. > I DON'T WANT TO HAVE TO WASTE MY TIME PROGRAMMING IT.
  116.  
  117. Hey, by making it a std, std functions can be provided for implementing it,
  118. and you'll have the code already available.  Do you complain about the
  119. operating system getting in your way of viewing the hardware?
  120.  
  121. I'll be adding support for everything that is resolved on this list to GEM++.
  122.  
  123.  
  124. Annius:
  125. > Hm.  Funny.  I just introduced shift close for iconify in Edith as
  126. > well.  A new standard for iconification in Single TOSes?
  127.  
  128. A MUCH safer technique is to use Shift-FULLER.  It also trains users to
  129. look on the right-hand side for the SMALLER.  It's also very meaningful,
  130. since the FULLER already means `Change Size', which is what iconification
  131. is all about.
  132.  
  133.  
  134. --
  135. Warwick
  136.